home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 438 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.0 KB
  1. Path: weck.brokersys.com!not-for-mail
  2. From: jguthrie@brokersys.com
  3. Newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.c,comp.lang.modula3,comp.lang.modula2,comp.lang.eiffel
  4. Subject: Re: Hungarian notation
  5. Date: 4 Jan 1996 09:00:48 -0600
  6. Organization: Executel/IBS Internet Services
  7. Message-ID: <4cgq30$c0v@weck.brokersys.com>
  8. References: <30C40F77.53B5@swsbbs.com> <marnoldDJEvtJ.1Lx@netcom.com> <4aleun$jlk@ns.RezoNet.NET> <marnoldDJMDBG.CFz@netcom.com> <4asnkr$7b0@solutions.solon.com> <4ath75$e7i@barnacle.iol.ie> <4b4kij$svt@news.microsoft.com> <dewar.819489496@schonberg> <4bd <4cf8hf$8fe@hopi.gate.net>
  9. NNTP-Posting-Host: weck.brokersys.com
  10. X-Newsreader: TIN [version 1.2 PL2]
  11.  
  12. Michael Feathers (feathers@gate.net) wrote:
  13. : : Why don't you just abandon the type declarations completely and use a
  14. : : prefix on the variable names to define the type?
  15.   
  16. : : My attitude remains the same:  Any naming convention works better than
  17. : : none, but embedding the type in the name is probably a bad idea.
  18.  
  19. : I really don't see why.  Hungarian is particularly useful in the
  20. : presence of polymorphism.
  21.  
  22. How does polymorphism make embedding the type in the name particularly useful?
  23.  
  24. : How can it hurt?
  25.  
  26. It hurts because you have to keep track of the type independantly of the
  27. actual type declaration.  Having to maintain that information in two places
  28. means that it won't ever get done.  When you change the type of a variable,
  29. (and this IS done from time to time even after primary coding is finished,)
  30. not only do you have to change the declaration, but also all the places where
  31. that variable appears no matter where it is or the information it gives you
  32. is wrong. Comments that lie are far worse than no comments at all.  The
  33. only description of what the code DOES is in the code itself, the comments
  34. (and other semantically insignificant clues in the program) should describe
  35. what the program is trying to accomplish, not how it accomplishes it.
  36.  
  37. I wasn't quite completely kidding when I suggested replacing normal variable
  38. declarations with a default type based upon the name prefix, it would be the
  39. obvious answer to my objection if it wasn't so much easier to just change
  40. one declaration than a dozen or so appearances.
  41.  
  42. I should also make it clear that, in the absence of name-based typing, I
  43. don't think the name of the identifier should be what is used to determine the
  44. type of the identifier.  On the contrary, it should reflect which module (or
  45. class or whatever the logical unit of functionality your language uses) the
  46. identifier is associated with (if it's in the global namespace) and it should
  47. somehow describe the use for which it is intended.  I actually liked the way
  48. that you could do stuff in Modula-2 that looks like
  49.  
  50. IMPORT Queue;
  51.  
  52. ...
  53.  
  54. VAR
  55.     FileList    : Queue.Type;
  56.  
  57. BEGIN
  58.  
  59.     FileList := Queue.Create();
  60.  
  61.     Queue.Add(FileList, OneElement);
  62.     Queue.Add(FileList, AnotherElement);
  63.     Queue.Sort(FileList);
  64.     Queue.Print(FileList);
  65.     Queue.Destroy(FileList);
  66. END
  67.  
  68. To be sure, the notation is clumsier than what you might have with C++, but it 
  69. certainly isn't any less clear.
  70.  
  71. Forgive me for rambling, please.
  72.